feat: committor service #366

thlorenz · 2025-05-15T09:19:50Z

Summary

Adding a full fledged committor service to support the following kind of commits:

commits up to 10Kb as long as the size increase per commit is <=1Kb
max accounts per bundle is 3 without lookup tables and 12 with lookup tables
commit results are persisted into a SQlite database in the ledger directory which makes it
easy to manually retry them or do this automatically (next committor version will support this)

Details

The following crates were developed
here and integrated
into the validator:

magicblock-rpc-client

thin wrapper around the solana rpc client with added features like improved transaction
signature status checking (including sane retries)
lookup table convenience methods
multi account fetch with known max limit
waiting for slots

magicblock-table-mania

a lookup table manager that allows to create, extend and deactivate + close lookup tables
the API supports reserving pubkeys which will be added to a table and when they need to be
used in a transaction the needed table addresses are provided
once a pubkey is released this is noted and a table is deactivated and closed on chain once
all its pubkeys are released

magicblock-committor-program

allows the committor service to upload account data to be committed in chunks
supports creation/resizing of buffers and filling them with transactions running in parallel
(out of order is ok)

magicblock-committor-service

commits a changeset as fast and efficiently as possible
first prefers transactions that don't require lookup tables since those take time to become
available
then prefers args only commits to the use of buffers (which require preparation)

Sample Flow

Validator starts up and reserves common pubkeys (used in all commits) with the committor
service
Account are cloned and for each account the pubkeys for commits are reserved to prepare the
lookup tables which we might need as fast as possible
Account(s) commit is scheduled and registered as we did before
The commits are processed via the committor service and the on chain transaction signature
is provided to the user via logs in a transaction (as we did before, just now we have to wait
for the commit to complete)

For those commits the committor service ensures that accounts with the same commit (bundle) id
are always processed atomically.

The committor service also picks the best possible strategy to commit each changeset,
preferring speed and then cost.

It also inserts configurable (via code) compute budget instructions to each transaction.

The outcome of each commit is persisted to a database which allows manual (and in the next
version) automated retries of failed commits.
Succeessful commits are also persisted to the database and can be used for diagnostics. In the
future they should be removed since no retry is necessary.

On chain signatures for process-commit/finaliz/undelegate transactions are also persisted to
the database in a separate table.

This table is queried by the validator to log those signatures as part of a transaction that
the user waits for.

Greptile Summary

This PR introduces a comprehensive committor service to the MagicBlock validator for managing account changes and transactions. The implementation includes a new Solana program for handling commits, a service layer for managing commit operations, and integration with lookup tables for transaction optimization.

Added magicblock-committor-program that handles chunked account data commits with proper buffer management and security checks
Added magicblock-committor-service that orchestrates commit operations with support for bundling, lookup tables, and persistent status tracking via SQLite
Added magicblock-table-mania for managing address lookup tables to optimize transaction sizes
Added magicblock-rpc-client with enhanced transaction handling and batched account fetching
Integrated committor service with existing account management systems while maintaining backward compatibility

- at this point schedule commit tests pass with maximum concurrency

- https://github.com/magicblock-labs/committor/tree/73f6a93d43995991fcc684b8853041f43fc19fa2

…m setup

This reverts commit 776bbf1.

…ing issues" This reverts commit aeeb5ae.

bmuddha

Good job at documenting the code so thoroughly, left some nits, I have to trust that the logic is sane and the test suite covers all the edge case, as trying to completely understand the entire interplay of all the components would take prohibitive amount of time.

bmuddha · 2025-05-18T17:07:15Z

magicblock-account-cloner/src/account_cloner.rs

+    res.await
+        .map_err(|err| {
+            // Send request error
+            AccountClonerError::CommittorSerivceError(format!("{:?}", err))


Suggested change

AccountClonerError::CommittorSerivceError(format!("{:?}", err))

AccountClonerError::CommittorSerivceError(format!("error sending request {err:?}"))

magicblock-account-cloner/src/account_cloner.rs

bmuddha · 2025-05-19T12:52:40Z

magicblock-accounts/src/remote_scheduled_commits_processor.rs

+        let max_slot = scheduled_commits
+            .iter()
+            .map(|commit| commit.slot)
+            .max()
+            .unwrap();
+        // Safety we just obtained the max slot from the scheduled commits
+        let ephemeral_blockhash = scheduled_commits
+            .iter()
+            .find(|commit| commit.slot == max_slot)
+            .map(|commit| commit.blockhash)
+            .unwrap();

+        changeset.slot = max_slot;


Suggested change

let max_slot = scheduled_commits

.iter()

.map(|commit| commit.slot)

.max()

.unwrap();

// Safety we just obtained the max slot from the scheduled commits

let ephemeral_blockhash = scheduled_commits

.iter()

.find(|commit| commit.slot == max_slot)

.map(|commit| commit.blockhash)

.unwrap();

changeset.slot = max_slot;

let mut changeset = Changeset::default();

let Some(commit) = scheduled_commits.iter().max_by_key(|commit| commit.slot) else {

return Ok(());

};

let max_slot = commit.slot;

let ephemeral_blockhash = commit.blockhash;

changeset.slot = max_slot;

I'd say we can safely unwrap()

Or keep this and remove empty check above

if scheduled_commits.is_empty() { return Ok(()); }

Yeah I agree that unwrap is ok. It is very clear that it is a logic (dev) error if we'd crash there (and in that case we'd want to instead of just happily returning Ok)

bmuddha · 2025-05-20T06:51:31Z

magicblock-committor-program/src/error.rs

+        msg!("Error: {:?}", e);
+        use CommittorError::*;
+        let n = match e {
+            UnableToSerializeChangeSet(_) => 0x69000,


What are those magic numbers? Some explanatory comments would be helpful

This is just us namespacing our errors. I tried to use a starting value that no other programs are using in order to be able to identify errors coming from our program. Any starting number will do here.

bmuddha · 2025-05-20T15:31:41Z

magicblock-table-mania/src/lookup_table_rc.rs

+    /// - *returns* `true` if the pubkey could be reserved
+    fn reserve(&self, pubkey: &Pubkey) -> bool {
+        if let Some(count) = self.pubkeys.get(pubkey) {
+            count.fetch_add(1, Ordering::SeqCst);


SeqCst is a total overkill, Relaxed would be totally correct as we are not synchronizing any other state through this atomic

I'm not 100% sure and if we get this wrong then we might end up with stuck lookup tables (which could be expensive for validator operators).
So at a minimal added cost when this method is called I attempt to prevent this.

I'm open to change this to relaxed if we ensure there is no way for race conditions.

bmuddha · 2025-05-20T15:34:37Z

magicblock-table-mania/src/lookup_table_rc.rs

+    fn release(&self, pubkey: &Pubkey) -> bool {
+        if let Some(count) = self.pubkeys.get(pubkey) {
+            count
+                .fetch_update(Ordering::SeqCst, Ordering::SeqCst, |x| {


ditto, SeqCst is an overkill, since no other state is synchronized

bmuddha · 2025-05-20T15:35:04Z

magicblock-table-mania/src/lookup_table_rc.rs

+    fn has_reservations(&self) -> bool {
+        self.pubkeys
+            .values()
+            .any(|rc_pubkey| rc_pubkey.load(Ordering::SeqCst) > 0)


ditto, Ordering::Relaxed is enough

bmuddha · 2025-05-20T15:37:13Z

magicblock-table-mania/src/lookup_table_rc.rs

+        })
+    }
+
+    /// Returns `true` if the we requested to deactivate this table.


Suggested change

/// Returns `true` if the we requested to deactivate this table.

/// Returns `true` if we have already requested to deactivate this table.

No need to get more wordy here (the already is basically a flller IMO).

bmuddha · 2025-05-20T15:51:27Z

magicblock-table-mania/src/manager.rs

+
+#[derive(Clone)]
+pub struct TableMania {
+    pub active_tables: Arc<RwLock<Vec<LookupTableRc>>>,


I guess some research was made to justify the usage of async synchronization primitives, i.e. they will be used in highly concurrent environments and with lock guards being held across await points, if not, then their use is unjustified.

taco-paco

Just some minor comments and questions.

taco-paco · 2025-05-21T09:26:55Z

magicblock-account-cloner/src/account_cloner.rs

@@ -66,6 +70,20 @@ pub enum AccountClonerUnclonableReason {
    DelegatedAccountsNotClonedWhileHydrating,
 }

+pub async fn map_committor_request_result<T>(


I would propose to use imp From<> for AccountClonerError to get rid of this function. It adds more indirection where code is really simple.

I prefer to have this be a very explicit conversion as we also include some more information on top.

I feel like ChangesetBundles::from would be explicit enough

taco-paco · 2025-05-21T09:33:05Z

magicblock-api/src/magic_validator.rs

+            "Committor service persists to: {}",
+            committor_persist_path.display()
+        );
+        let committor_service = Arc::new(CommittorService::try_start(


That goes out from usual flow of services. Would be good to start it from Validator::start along with other services

If I remember correctly specific services have to be started only after some other services are started already.
Here we start all those services together in the right order.

I felt it was due to separation: instance creation, start work

taco-paco · 2025-05-21T09:53:17Z

magicblock-committor-service/src/service.rs

For ease of reading I think Actor shall be moved to its personal file

I don't agree as the actor is just the internal impl of the API interface and both are tightly coupled, thus makes sense to have them in the same module.

taco-paco · 2025-05-22T09:05:53Z

magicblock-rpc-client/src/lib.rs

+    RpcClientError(#[from] solana_rpc_client_api::client_error::Error),
+
+    #[error("Error getting blockhash: {0} ({0:?})")]
+    GetLatestBlockhash(solana_rpc_client_api::client_error::Error),


Are those errors intended to be handled? Not sure we need error per rpc entrypoint. If we want to have extra context I'd suggest logging instead

In a more core lib (which this is) you don't want to just log, but provide detailed errors ror the upper level logic to handle, i.e. it might handle a missing blockhash differently than a deserialization error.
If we don't provide different errors for those cases then this is not possible.

taco-paco · 2025-05-24T09:16:49Z

magicblock-table-mania/src/manager.rs

+        };
+
+        let storing = remaining[..storing_len].to_vec();
+        let stored = table


We could make this work without new allocations at all.

We just pass &mut remaining into extend_respecting_capacity, which would pop from the back pubkeys it needs

taco-paco · 2025-05-26T06:08:34Z

magicblock-committor-service/src/transactions.rs

+
+/// How many process and commit buffer instructions fit into a single transaction
+#[allow(unused)] // serves as documentation as well
+pub(crate) const MAX_PROCESS_PER_TX: u8 = 3;


How were those consts determined? I think also worth adding this information as comment

See tests below in this file

taco-paco · 2025-05-26T06:08:52Z

magicblock-committor-service/src/transactions.rs

+/// when using address lookup tables but not including the buffer account in the
+/// lookup table
+#[allow(unused)] // serves as documentation as well
+pub(crate) const MAX_PROCESS_PER_TX_USING_LOOKUP: u8 = 12;


How were those consts determined? I think also worth adding this information as comment

See tests below in this file

magicblock-committor-service/src/transactions.rs

taco-paco · 2025-05-26T06:55:58Z

magicblock-committor-service/src/commit_strategy.rs

+            .first()
+            .map(|(_, acc)| acc.bundle_id())
+            .unwrap_or_default();
+        Err(CommittorServiceError::CouldNotFindCommitStrategyForBundle(


Feels like a very critical error. It pretty much breaks a contract that validator has with user - you can commit and undelegate your state, With this it's not true anymore.
it actually shall be slashable when validator doesn't commits or undelegates your state. Now it will be hard to handle this.

I think our magicblock-program shall have some surface-level check to reject impossible commits. Like if number of accounts to commit somehow > 32*256 (possible with lookup tables) we panic. or even > 30 * 256. Also we could pretty easily calculate overall sizes of committed accounts and make some estimates.

Thesis is: if something made it into scheduled_commits it has to be commited, otherwise validator is slashed. So here we need to panic really

Interesting idea. However our validator needs to keep running in these cases and there is no direct way to communicate this back to the user. Keep in mind that it is the program that schedules commits, so there is no way this is the validator's fault if we exceed limits. Instead we fail those commits and keep an entry in our DB which we can then query in order to provide feedback to program authors about those violations. For now manually, but possibly we may provide a query interface for validator operators or even users as well (i.e. as part of a dashboard).

taco-paco · 2025-05-28T06:55:32Z

magicblock-accounts/src/remote_scheduled_commits_processor.rs

-                            undelegation_requested: commit.request_undelegation,
-                        });
+                        committees.push((
+                            commit.id,


No need in commit.id here. In committees vector the all belong to same id

We need that id further down.

Couldn't find it, maybe missed it. Which part do you refer to?

taco-paco · 2025-05-28T06:56:42Z

magicblock-accounts/src/remote_scheduled_commits_processor.rs

+                        lamports: committee.account_data.lamports(),
+                        data: committee.account_data.data().to_vec(),
+                        owner: committee.owner,
+                        bundle_id,


Suggested change

bundle_id,

commit.id,

bundle_id can removed

taco-paco · 2025-05-28T07:42:07Z

magicblock-committor-service/src/persist/commit_persister.rs

Do we ever clean the entries up?

taco-paco · 2025-05-28T07:58:05Z

magicblock-rpc-client/src/lib.rs

+
+    pub fn ensure_processed() -> Self {
+        Self::SendAndConfirm {
+            wait_for_blockhash_to_become_valid: Some(Duration::from_millis(


Not sure we need all of the Options in MagicBlockSendTransactionConfig if all of those are defined, or defaulted to some value during runtime.
MagicBlockSendTransactionConfig can get rid from all the Options

This library is intended to be used in more cases in the future (than just from the committer service). Therefore I made them configurable.

taco-paco · 2025-05-28T07:58:51Z

magicblock-rpc-client/src/lib.rs

+            wait_for_commitment_level
+        {
+            let now = Instant::now();
+            let check_for_commitment_interval = check_for_commitment_interval


Value can be defaulted to this on construction if not set.

I wanted to do this at last possible moment and closer to the code that uses it.

taco-paco · 2025-05-28T08:12:15Z

magicblock-accounts/src/remote_scheduled_commits_processor.rs

+                .map(|account| account.bundle_id)
+                .collect::<HashSet<_>>()
+            {
+                let bundle_signatures = match changeset_committor


Why don't we return all of the signatures as result of commit_changeset?

That would allow us to clean entries right away from persister.

At this point all of the signatures already available, this call just reads them from db.

I agree we could, but I don't want to introduce two sources of truth.
The idea is to return minimal info as part of the result and only if more details are needed do we query the DB.

This would be 1 source of truth - returned value.

I see 2 problems with the other way around:

we perform I/O for something that is result of function

Persister isn't cleaned

Source of truth is that is in the DB, we don't have to also return it IMO.

I/O is only needed if something goes wrong.

Cleaning of persister (removing rows for successful commits) will be added in a follow up once we saw everything working as expected.

taco-paco · 2025-05-28T08:30:30Z

magicblock-account-cloner/src/remote_account_cloner_worker.rs

+
+                // Allow the committer service to reserve pubkeys in lookup tables
+                // that could be needed when we commit this account
+                map_committor_request_result(


It looks like all pubkeys will be in some lookup table, even when they're not needed to. For example, do we need this in case when we can commit using just arguments?

Why don't we create tables only when necessary?

We don't know this ahead of time, but need to prepare for the case where we do need them in order to save time in that case. This was a nice optimization idea by @bmuddha

That's a valid point, but the other side is that validator pays when this may not be needed. I don't think waiting for txs to land in this case is so critical.

But it depends what we want to opimize at the end

We optimize for fast commits

taco-paco · 2025-05-28T08:34:22Z

magicblock-table-mania/src/manager.rs

What happens with TableMania if validator is restarted?
It looks like if validator is restarted we would start from scratch, creating lookup tables for pubkeys, that actually are already in some lookup table

That's a great observation. Remember that we derive the tablemania pubkeys deterministically which allows to find old tables and close them later to refund cost to the validator.
The alternative would be to delay validator stop for a few slots until we were able to deactivate and then close all tables (not a good solution IMO).

taco-paco · 2025-05-28T08:48:27Z

magicblock-table-mania/src/manager.rs

Why do we need the garbage collector TableMania? Unless I miss something, now it looks like:

once some account per pubkey is cloned, we extend/create a new table, or do nothing.

once the addresses in table all undelegated it can be cleaned up.

From here I don't see why we need garbage collector:

Ideally use tables only when its required for successful commit. Insert/extend/do nothing(if present) as per current logic

Once the last key in some table is released - deactivate table right away.

No need for garbage collector.

We need to first deactivate the table (checking in the background if that is possible).
Then we need to wait for a few slots until we can close it.

We cannot do this as part of the flow which needs to be fast.

No, the part of asynchronous deactivation is fine with me) By garbage collector I also implied our reference counting and all that logic. It isn't needed in this flow. Even in current implementation the tables will be marked deactivated. so we can just completely remove garbage collection based on reference counting.

How is that not needed? We need to know which pubkeys are still in use in order to know which tables can be deactivated and later closed. Keep in mind that we want to clean up the lookup tables as soon as possible, i.e. when we know that certain accounts were undelegated and thus will no longer be committed until they are delegated and cloned again.

taco-paco · 2025-05-29T05:49:44Z

magicblock-committor-program/Cargo.toml

I'd suggest keeping it ./programs folder

That folder is for programs that are part of our ephemeral validator. This program will be deployed on dev/mainnet, so it is different (more like the delegation program which is even in a separate repo)

taco-paco · 2025-05-29T06:12:32Z

Cargo.toml

@@ -111,8 +102,13 @@ magicblock-accounts-api = { path = "./magicblock-accounts-api" }
 magicblock-accounts-db = { path = "./magicblock-accounts-db" }
 magicblock-api = { path = "./magicblock-api" }
 magicblock-bank = { path = "./magicblock-bank" }
+magicblock-committor-program = { path = "./magicblock-committor-program", features = [


nitpick: we now have services ending with committor and committer, like RemoteAccountCommitter.
committor must be a typo

No, everything in the committor-service is committor. RemoteAccountCommitter existed before.
It's a solana thing as we are buildooors. I'm trying to keep our codebase fun :)

Copilot

Pull Request Overview

This PR introduces a full committor service to support efficient, atomic account commits with integration across multiple modules including the new committor program, service, and lookup table management. Key changes include:

Adding new crates (magicblock-committor-program and magicblock-committor-service) to handle commit data, buffer management, and persistence via SQLite.
Integrating the committor service into the validator and account processing pipelines by updating the APIs and tests.
Updating error handling and dependency configurations across several modules to support the new commit flows.

Reviewed Changes

Copilot reviewed 118 out of 118 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
magicblock-committor-program/src/consts.rs	Introduces new constant definitions supporting commit limits.
magicblock-api/src/tickers.rs	Integrates committor service references in slot ticker processing.
magicblock-api/src/magic_validator.rs	Incorporates committor service for reserve and commit operations.
magicblock-api/src/errors.rs	Adds new error variants including validator funding and committor.
magicblock-accounts/*	Updates signatures and test setups to propagate changeset_committor.
magicblock-account-cloner/*	Adjusts account cloning and error mapping to use changeset_committor.
Cargo.toml (workspace root and sub-crates)	Updates dependencies and workspace members for new committor crates.

Comments suppressed due to low confidence (1)

magicblock-accounts/src/remote_scheduled_commits_processor.rs:216

[nitpick] The process_changeset function contains several nested operations; consider refactoring parts of its logic into smaller helper functions to improve readability and maintainability.

    fn process_changeset<CC: ChangesetCommittor>(...) {

magicblock-api/src/errors.rs

magicblock-accounts/src/errors.rs

* master: feat: update mdp dependency + tests fix: use mutiple connections for ws subscriptions (#365) feat: allow for multiple ws endpoints in remote config (#372) Raise mdp version + update artifacts & improve error logging (#368)

taco-paco · 2025-06-05T06:35:59Z

magicblock-committor-service/src/commit_strategy.rs

+            CommitBundleStrategy::try_from((bundle, finalize))?;
+        match commit_strategy {
+            CommitBundleStrategy::Args(bundle) => {
+                add_to_changeset(


is it safe to append on new iteration to same args_changeset?

Say we have 2 bundles:
Iteration 1 - we get CommitBundleStrategy::Args and push to args_changeset.
Iteration 2 - we get CommitBundleStrategy::Args and push to args_changeset.

Now the issue it that if bundle in Iteration 1 and 2 separately fit into args, doesn't mean they both will.

Looking into commit_changeset_using_args it doesn't handle them on bundle levels but tries create a single tx with data from 2 Iterations

taco-paco · 2025-06-05T09:03:26Z

magicblock-committor-program/src/state/changeset.rs

+        pubkey: Pubkey,
+        account: T,
+    ) -> bool {
+        self.accounts.insert(pubkey, account.into()).is_some()


/// If it already exists, it will be replaced, thus the caller needs

I think that could be an issue, assume actions.
Imagine:

Bob makes a CommitWithActions with some accounts [acc1, acc2], and actions [a1, a2]. commit_id = 1

Bob makes a CommitWithActions with some accounts [acc2, acc3], and actions [a3, a4]. commit_id = 2

At this point we would replaced acc2 with commit_id = 1, to acc2 with commit_id = 2. As result for commit_id/bundle_id = 1 we would commit [acc1] with actions [a1, a2], when user expected both of them to be commited, and action could be connected to state of acc2.

Shouldn't we keep all accounts per commit_id, and not replace them?
like:
First [acc1, acc2], and actions [a1, a2], then [acc2, acc3], and actions [a3, a4]
cc @GabrielePicco

* master: Optimizing column entries bookkeeping (#393) Update README.md (#396) Revert to using separate tokio runtime instance for RPC (#395) feat: fix release workflow (#392) Compaction V1: Manual compaction (#383) release: v0.1.3 (#391) Log validator version on startup (#390) Update README.md (#384) PubSub redesign from broadcast to multicast (#373)

* master: release: v0.1.7 (#409) Feat: simpler gasless implementation (#406) perf: run ensure accounts concurrently feat: account hydration on background task (#407) Revert "feat: Cleaner gasless implementation" (#405) feat: Cleaner gasless implementation (#360) fix: cleanup slots on non-fresh ledger (#404) release: v0.1.5 (#403) fix: properly init geyser plugin for rpc and use valid dummy Library (#402) release: v0.1.4 (#401) fix: remove grpc plugin altogether from geyser manager (#400) Patch tests from failing on subscription due to rate limits (#386)

thlorenz added 30 commits May 7, 2025 11:10

test: add realloc ix to flexi counter

45bdf72

chore: resort workspace depencencies

2e61882

chore: retire old remote scheduled commits processor and add new one

6806acf

feat: initial impl of commits processor based on committor service

8cdc141

feat: initializing committor service at startup

c0d08a4

test: logging signature of failed init_committees tx

9eed608

test: adapt to expect two signatures when finalizing

dae8ea8

feat: ensure ephemeral validator is funded on chain

80e6777

test: add single account commit test

3078a1c

test: warn when we have issues fetching a transaction

8391124

fix: adding change for validator fund check

e5aa347

feat: fully integrating committor service

be98740

chore: update ix tests cargo

5ce7a20

chore: comment with requirements for schedule commit tests

b54cd3b

chore: improve test logs

dc2da58

chore: include compute unit price when initializing committor

560fd6b

fix: mark accounts to be undelegated

b3445c1

chore: properly handle some unwraps

24bb27a

test: general improvements + fixes

cc389e7

- at this point schedule commit tests pass with maximum concurrency

chore: use trait for committor service and create stub to use in tests

f7304cf

chore: update ensure accounts tests to use stub

04b0116

chore: re-enable account cloner and ensure accounts tests

d770b95

chore: move committor repo crates into magicblock monorepo

88dd40b

- https://github.com/magicblock-labs/committor/tree/73f6a93d43995991fcc684b8853041f43fc19fa2

chore: move committor service integration tests

e6f1edd

chore: noting escrow/fee payer related test requirements

1c4dd78

chore: minor cleanup in test runner

8c620fe

ix: load committor program for schedule commits

f3e17d1

ix: allow configuring loaded accounts

6d109f9

ix: match ephem validator keypair to the one we use on chain

0dceb8b

ix: ensure we always pass same loaded chain accounts to chain + ephen…

7fdc795

…m setup

thlorenz added 3 commits May 16, 2025 17:10

fix: ordering of worker startups

aedf9a2

Revert "tmp: disabling ledger restore tests to isolate issues"

1e9921d

This reverts commit 776bbf1.

Revert "tmp: disable all workflows but integration tests while isolat…

0e0ef0f

…ing issues" This reverts commit aeeb5ae.

bmuddha approved these changes May 20, 2025

View reviewed changes

taco-paco requested changes May 26, 2025

View reviewed changes

taco-paco reviewed May 29, 2025

View reviewed changes

chore: address nits

2bfd49f

GabrielePicco requested a review from Copilot June 4, 2025 07:34

Copilot AI reviewed Jun 4, 2025

View reviewed changes

magicblock-api/src/errors.rs Show resolved Hide resolved

magicblock-accounts/src/errors.rs Show resolved Hide resolved

thlorenz added 3 commits June 4, 2025 14:53

Merge branch 'master' into thlorenz/committor

05bbaec

* master: feat: update mdp dependency + tests fix: use mutiple connections for ws subscriptions (#365) feat: allow for multiple ws endpoints in remote config (#372) Raise mdp version + update artifacts & improve error logging (#368)

chore: update cargo lock files

4d1b44f

chore: match mdp version

9e091fc

taco-paco reviewed Jun 5, 2025

View reviewed changes

taco-paco approved these changes Jun 16, 2025

View reviewed changes

thlorenz and others added 14 commits June 18, 2025 16:06

Merge branch 'master' into thlorenz/committor

67b98bd

chore: move can_clone method to clone permissions itself

9ee833d

feat: only launch committor service if we aren't in offline mode

8610bce

chore: update committor program id

10bdf51

chore: use up todate tmpdir method to keep directory

d594ba8

chore: remove obsolete DecoderError impl

ff313fd

chore: disable type complexity warning

088be94

ix: allow specifying integration tests to run

7a725ae

feat: log amount of accounts we tried to commit when it fails

1ab5d7e

test: printing script to start test validator for specific setup

cd219cc

test: reproduced committor service issue of too large tx in ix test

c0eec86

fix: wrongful combination of multiple bundles into single changeset

fe9860f

	AccountClonerError::CommittorSerivceError(format!("{:?}", err))
	AccountClonerError::CommittorSerivceError(format!("error sending request {err:?}"))

	/// Returns `true` if the we requested to deactivate this table.
	/// Returns `true` if we have already requested to deactivate this table.

feat: committor service #366

Are you sure you want to change the base?

feat: committor service #366

Uh oh!

Conversation

thlorenz commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

magicblock-rpc-client

magicblock-table-mania

magicblock-committor-program

magicblock-committor-service

Sample Flow

Greptile Summary

Uh oh!

bmuddha left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taco-paco left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

thlorenz commented May 15, 2025 •

edited

Loading

taco-paco left a comment •

edited

Loading